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Abstract.  In  this  paper,  we  present  the  emerging  force  template  model  for  the  Joint  Battlespace  Infosphere  (JBI)  and 
discuss  how  it  supports  successful  coalition  operations.  Infosphere  architectures,  such  as  the  JBI,  represent  the  way 
ahead  for  leveraging  web  and  e-commerce  technologies  to  streamline  command,  control,  and  intelligence  (C2I) 
operations.  We  introduce  the  force  template  concept  as  the  principal  mechanism  to  quickly  integrate  battlespace 
entities  (and  their  clients)  into  the  JBI.  Additionally,  we  show  how  force  templates  can  ensure  proper  information 
dissemination  within  the  JBI.  With  its  emphasis  on  resource  exchange  and  control,  force  templates  provide  the 
flexibility  needed  to  seamlessly  share  information  among  members  of  ad-hoc  coalitions. 

1.  Introduction. 

There  are  many  areas  where  technology  has  not  caught  up  to  military  strategy  and  doctrine— coalition 
warfare  is  one  of  these.  Future  military  operations  will  require  close  coordination  and  information  sharing 
among  heterogeneous  units,  coalition  forces,  and  other  civil  and  non-governmental  (NGO)  organizations. 
While  United  States  increasingly  relies  on  coalitions  to  achieve  its  military  objectives,  the  technological 
infrastructure  necessary  to  support  this  strategy  has  been  lacking.  The  gulf  between  the  desired  and  the 
possible  is  especially  glaring  in  the  area  of  C2I.  For  example,  in  the  Joint  Force  Expeditionary  Experiment 
(JEFX)  ‘99,  the  effort  to  integrate  coalition  members  into  the  Combined  Air  Operations  Center  (CAOC) 
was  deemed  a failure.  This  result  was  due  to  three  factors:  US-only  applications  within  Theater  Battle 
Management  Core  Systems  (TBMCS),  use  of  SIPRNET  as  the  CAOC  backbone,  and  the  population  of 
CAOC  databases  with  US-only  information  [3].  The  changes  required  to  remedy  this  situation  were 
sufficiently  difficult  as  to  result  in  the  cancellation  of  the  planned  coalition  operations  in  JEFX  ’00  [4]. 

One  of  the  key  recommendations  from  JEFX  ’99  was  to  develop  a CAOC  backbone  accessible  by  all 
coalition  users  [3].  While  some  approaches  include  explicitly  tagging  database  elements  for  releasibility,  a 
cleaner  solution  requires  a new  paradigm  that  manages  information  in  terms  of  standardized,  discrete 
objects.  Such  an  approach  would  enable  the  following  positive  developments: 

• The  segregation  of  information  objects  from  their  source  applications  and  databases. 

• Making  publish,  subscribe,  query,  and  transformation  capabilities  available  to  producers  and 
consumers  of  these  information  objects. 

• The  specification  of  policy  governing  how  the  published  object  types  can  be  disseminated  within 
the  infosphere. 

Currently,  information  potentially  releasable  to  coalition  partners  is  often  combined  with  other, 
sensitive  data  within  client  applications  and  databases.  The  unfortunate  result  is  a denial  of  useful 
information  to  coalition  partners  since  the  aggregated  data  is  at  a system  high  level.  Segregating 
information  into  packages  that  are  small,  coherent,  and  discrete  makes  it  easier  to  control  and,  therefore, 
distribute  to  other  coalition  members. 

It  is  also  possible  to  convert  some  sensitive  data  into  a releasable  form.  In  many  cases,  lightweight 
programs  (referred  to  as  fuselets)  could  be  employed  to  accomplish  these  transformations.  Policy 
associated  with  information  objects  (nominally  defined  by  the  publishers)  will  determine  to  whom,  and  in 
what  form,  specific  objects  would  be  disseminated.  The  combination  of  an  infosphere,  better  information 
packaging,  and  fuselets  would  facilitate  the  controlled,  secure  sharing  of  information  within  a coalition. 


125 


2.  The  Joint  Battlespaee  Infosphere. 

The  JBI  is  a system  of  systems  that  integrates,  aggregates,  and  distributes  information  to  users  at  all 
echelons,  from  the  command  center  to  the  battlefield.  Infospheres  are  a critical  stepping  stone  to  solving 
the  problems  of  coalition  C2I  integration  because  they  inherently  provides  many  of  the  capabilities 
described  in  the  previous  section.  The  conceptual  framework  for  JBI  was  outlined  in  two  consecutive  Air 
Force  Scientific  Advisory  Board  (SAB)  reports.  Information  Management  to  Support  the  Warrior  (1998) 
[5]  and  Building  the  Joint  Battlespaee  Infosphere  (1999)  [6],  The  SAB  vision  for  the  JBI  encompasses  the 
four  key  concepts  described  below  and  in  Figure  1 . 

Information  exchange  through  publish,  subscribe,  and  query.  This  capability  enables  the  user  to 
locate  and  subscribe  to  information  resources  available  within  the  JBI.  Each  publisher  is  responsible  for 
tracking  users  that  have  subscribed  to  its  resources.  When  an  information  resource  is  published,  a tailored 
version  of  that  resource  is  forwarded  to  the  subscriber. 

Transforming  data  to  knowledge  via  fuselets.  Fuselets  are  lightweight  programs  or  scripts  that 
process  incoming  information  objects  received  from  established  subscriptions.  When  these  objects  arrive, 
fuselets  can  then  aggregate,  correlate,  and/or  transform  them  into  information  of  interest  to  a given 
subscriber. 

Distributed  collaboration  through  shared,  updateable  knowledge  objects.  This  concept  refers  to 
the  ability  of  the  JBI  to  facilitate  collaborative  problem  solving  among  multiple,  diverse  users. 

Assigned  unit  incorporation  via  force  templates.  A force  template  is  an  electronic  description  of  an 
entity  that  enables  its  integration  into  the  JBI  (including  all  its  subcomponents). 
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Figure  1 - JBI  Capabilities 
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3.  Force  Template  Concepts 


In  this  section,  we  build  on  the  definition  given  in  the  last  section  by  discussing  why  force  templates 
are  needed,  how  they  model  coalition  units,  and  what  information  they  provide  to  the  JBI. 

Why  are  force  templates  needed?  While  the  JBI  provides  platform  for  information  transfer,  others 
must  provide  the  content.  For  an  infosphere  to  have  value,  the  participating  entities  must  “plug  in”  and  use 
it  to  exchange  information  and  service  resources.  The  force  template  contains  the  information  that  enables 
operational  entities  within  the  battlespace  (and  their  clients)  to  quickly  interact  using  the  JBI  platform. 

The  force  template  also  includes  the  context  and  policy  that  define  an  entity’s  contract  with  the  JBI. 
One  of  the  key  motivations  for  developing  the  force  template  concept  is  the  need  to  allow  the  JBI  to  grow 
(shrink)  in  a modular  fashion  that  reflects  the  phase  of  the  associated  military  operation.  In  short,  the  JBI 
must  handle  dramatic  and  sudden  content  changes  while  maintaining  an  acceptable  level  of  service. 

Without  the  force  template  mechanism,  it  becomes  extremely  difficult  to  track  and  manage  the  changes  to 
JBI  content  resulting  from  the  arrival  and  departure  of  coalition  units. 

Entities,  Clients,  and  Passes.  An  entity  is  an  organization  that  decomposes  into  multiple  components. 
Those  components  may  either  be  other  entities  (child  entities)  or  clients.  In  this  model,  entities  primarily 
correspond  to  operational  military  units  and  the  organizations  that  support  them.  Both  parent  and  child 
entities  may  have  their  own  force  templates.  For  example,  a wing  and  its  associated  squadrons  may  each 
have  their  own  force  templates.  These  templates  may  be  separate,  but  linked  based  on  their  relationship. 
The  level  at  which  force  templates  are  required  should  reflect  the  modularity  of  the  force  (e.g.,  the  level  at 
which  forces  can  be  mixed,  matched,  or  tasked). 

Clients  are  owned  by  entities.  It  is  intended  that  clients  correspond  to  specific  individuals,  systems, 
applications,  repositories,  or  platforms.  For  example,  an  F-15  client  may  be  owned  by  a fighter  squadron 
entity.  A client  will  interface  directly  with  the  JBI  on  behalf  of  its  owner.  Unlike  entities,  clients  may  not 
decompose  into  subcomponents.  The  entity  that  owns  a client  must  be  registered  before  the  client  can 
connect  to  the  JBI  platform.  Entities  at  any  level  may  own  a distinct  set  of  clients.  The  entity  client 
relationship  is  illustrated  in  Figure  2. 

A pass  is  an  electronic  description  of  a client  that  enables  it  to  interface  with  the  JBI.  The  pass  defines 
what  a client  may  do  when  connected  to  the  JBI.  This  is  primarily  expressed  in  terms  of  authorized  client 
publications  and  subscriptions.  The  information  in  the  pass  must  be  consistent  with  the  force  template  of 
the  entity  that  owns  the  client.  The  differences  between  force  templates  and  passes  are  summarized  in 
Table  1. 


Table  1 - Comparison  of  Force  Template  and  Passes 

Force  Template 

Pass 

Purpose 

Register  entities  with  JBI 

Register  clients  with  JBI 

Activation 

Prerequisite 

Approval  of  Joint  Force  Commander 
(JFC)  or  parent  entity 

Registration  of  owner  entity’s  force 
template  with  the  JBI 

JBI  Interface 

Force  template  controller 

Client  adapter 

Content  Characteristics 

Distributed,  hierarchical, 
decomposable 

Consolidated,  cannot  be  decomposed 

Minimum  Contents 

- Entity  info  requirements 

- Entity  info  products 

- Entity  level  constraints 

- Passes  for  clients  owned  by  the 
entity 

- Info  object  advertisements 

- Subscription  requests 

- Client  level  constraints 
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Force  template  contents.  There  is  a wide  spectrum  of  information  that  the  force  template  could 
potentially  provide  the  JBI.  Some  items  are  essential  for  the  operation  of  the  JBI;  others  are  extensions  of 
the  capabilities  outlined  in  the  SAB  report.  As  a result,  three  separate  categories  are  used  to  characterize 
force  template  content;  these  are:  necessary,  desired,  and  speculative  (also  see  Figure  3). 
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Figure  2 - Entity/Client  Relationship 


Necessary  Contents: 

Information  needed  by  the  entity.  This  refers  to  information  that  the  entity  says  it  needs  to  function 
within  the  theater.  Information  can  be  requested  in  terms  of  categorical  requirements  (expressed  as  a 
metadata  query)  or  in  terms  of  specific  information  object  types  (predefined  subscription  requests). 

Information  provided  by  the  entity.  This  refers  to  information  that  the  entity  says  it  can  provide 
within  the  theater.  These  will  likewise  be  expressed  using  metadata  descriptions  or  in  terms  of  specific 
information  object  types  (advertisements). 

The  constraints  associated  with  the  above.  In  many  cases,  information  provided  or  requested  will 
have  constraints  associated  with  it.  Examples  of  subscriber  constraints  include  desired  quality  of 
service,  pedigree,  preferred  sources,  and  required  delivery  windows.  Examples  of  publisher 
constraints  include:  anticipated  publication  times  and  rates,  and  dissemination  constrains.  These 
constraints  may  also  be  expressed  in  terms  of  rules  about  information  object  content.  In  this  case, 
publisher  advertisements  may  also  include  information  on  publisher  capabilities  (such  as  filtering  and 
query  capabilities).  The  JBI  platform  will  use  these  constraints  to  broker  information  requirements 
against  available  information  products 

Security  Information.  This  is  a broad  and  evolving  category.  The  force  template  could  provide  a 
number  of  security  related  items  to  the  JBI.  This  may  include: 

- The  identity  and  security  credentials  for  individuals  occupying  key  unit  positions. 

- Public  keys  for  specific  clients  (individuals,  platforms,  or  systems). 
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- Dissemination  limitations  on  published  information. 

Desired  Contents: 

Information  Pedigree.  This  refers  to  indicators  of  the  quality,  reliability,  and  integrity  of  entity 
publications.  As  such,  pedigree  ratings  may  be  provided  in  part  by  the  entity  (self-assessment)  and  in 
part  by  the  JBI  (based  on  previous  history  or  consumer  experience). 

Mapping  of  Specific  Personnel  to  Operational  Roles.  Force  templates  for  similar  units  will  have  a 
high  degree  of  commonality  that  extends  to  positions  within  the  unit.  The  force  templates  will 
communicate  to  the  JBI  which  personnel  are  authorized  to  function  in  those  positions.  This  mapping 
could  enable  the  JBI  Info  Management  Staff  (IMS)  to  issue  the  proper  security  certificates  for  those 
individuals. 
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Figure  3 - Force  Template  Content 


Entity  Description.  This  will  describe  the  characteristics  of  the  entity  interfacing  with  the  JBI. 

Ideally,  this  will  take  the  form  of  a “resource  map”  (similar  to  an  active  directory)  that  describes  all 
entity  components  (e.g.,  devices,  clients,  data  sources,  and  people)  visible  to  the  JBI.  It  also  includes 
the  child  entities  that  compose  the  entity  (e.g.,  squadrons  within  a wing).  Each  item  on  the  map  will 
list  the  characteristics  of  the  particular  resources.  Examples  of  some  unit  characteristics  include: 
mission  description,  unit  organizational  structure,  location,  capability  description,  resource  maps,  and 
pointers  to  associated  force  templates. 

Speculative  Contents: 

Ontologies  and  Ontology  Mappings.  The  more  diverse  the  coalition,  the  greater  the  importance  of 
shared  semantics.  For  coalition  operations  to  be  successful,  it  is  essential  that  a consistent  set  of  terms 
be  used  to  facilitate  information  sharing  [1].  As  a result,  it  is  desirable  to  include  ontologies  specific  to 
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an  entity,  system,  or  related  domain.  Whenever  possible,  these  ontologies  should  come  with  mappings 
to  common  ontologies  utilized  within  the  JBI. 

F uselets.  Fuselets  may  be  associated  with  either  publications  or  subscriptions.  Examples  include 
XSLT,  Excel  spreadsheets,  Active-X  components,  or  Java  beans.  Ideally,  the  force  template  would 
contain  references  to  fuselets  available  from  the  entity.  These  fuselets  should  be  associated  with 
specific  publications  within  the  JBI  (but  not  necessarily  by  the  providing  entity). 

Process  Models,  Rules,  and  Constraints.  These  items  describe  how  the  entity  does  business  in  the 
theater  of  operations.  Ideally,  these  will  be  specified  in  terms  of  the  included  ontologies. 

Available  Services,  or  Agents.  These  items  describe  services  provided  by  the  entity  for  use  by  other 
(appropriate)  JBI  entities.  Examples  of  services  might  include:  computation  of  look  angles  for 
satellites,  requests  for  surveillance  of  certain  areas,  and  agent  services  for  determining  unit  personnel 
location  and  status. 

4.  Entity/Client  Interaction  Model 

The  SAB  report  painted  a general  picture  of  what  the  JBI  should  do  and  what  technologies  it  might 
leverage.  It  did  not,  however,  provide  guidance  on  how  the  JBI  should  behave.  Since  there  is  no  official 
model  for  interaction  with  the  JBI,  we  will  take  a first  cut  developing  one  here.  The  model  proposed  here 
(summarized  in  Figure  4)  ensures  the  following  requirements  are  met: 

- The  JBI  platform  has  visibility  and  control  over  its  inputs  and  outputs. 

- Entities  maintain  control  over  what  their  clients  are  allowed  to  do  within  the  JBI  through  the 
force  template  infrastructure. 

- Dynamic  changes  to  the  force  template  can  be  made  after  registration,  allowing  the  flow  of 
information  to  evolve  during  the  mission.  These  changes  may  be  initiated  by  the  top  down 
(from  the  parent  entity  or  the  JBI  information  staff)  or  from  the  bottom  up  (by  the  client). 

- The  integrity  and  consistency  of  associated  force  templates  and  passes  are  maintained. 

The  first  part  of  the  model  deals  with  the  registration  of  the  entity  with  the  JBI.  The  notional  steps  in 
the  process  are  listed  below. 

1 . Locate  the  appropriate  JBI. 

2.  Entity  requests  permission  to  connect  to  JBI  platform. 

3.  JBI  requests  force  template  package  from  entity. 

4.  The  entity  transmits  its  force  template  to  the  JBI  platform. 

5.  JBI  processes  force  template  package. 

6.  JBI  tenders  response:  acceptance,  partial  acceptance,  or  rejection. 

7.  If  acceptance  is  granted,  a controller  process  is  elaborated  for  the  force  template. 

As  discussed  earlier,  the  entity  must  register  prior  to  registration  of  its  clients.  Clients  will  not  be 
allowed  to  register  with  the  JBI  until  an  acceptance  or  partial  acceptance  is  tendered.  It  is  assumed  that 
child  entities  are  not  required  to  register  before  their  parents.  This  feature  offers  flexibility  in  extending  the 
JBI  in  cases  such  as  when  individual  squadrons  deploy  to  a theater  without  their  parent  wing. 

The  acceptance  of  the  entity’s  force  template  triggers  the  allocation  of  a Force  Template  Controller 
(FTC)  within  the  JBI  platform.  The  FTC  is  a gatekeeper  that  ensures  clients  behave  in  a manner  consistent 
with  the  force  template.  It  also  controls  changes  to  the  force  template  that  may  occur  during  the  entity’s 
JBI  session.  These  changes  may  be  initiated  from  the  bottom  up  (e.g.,  client  wishes  to  publish  a new 
information  object  type)  or  from  the  top  down  (e.g.,  parent  of  entity  or  JBI  information  staff  mandates 
changes  to  the  force  template). 
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The  proposed  client  interaction  model  is  illustrated  above.  The  steps  for  registration  of  individual 
clients  are  listed  below. 

1 . The  FTC  ensures  that  adapter  processes  are  elaborated  for  each  client  associated  with  the 
entity’s  force  template. 

2.  The  passes  associated  with  the  clients  are  cleared  for  activation  within  the  JBI.  The 
individual  clients  may  attempt  connection  to  the  JBI. 

3.  The  client  registers  with  the  JBI  through  its  associated  adapter. 

4.  The  adapter  validates  the  client.  It  then  receives  permission  to  interact  with  the  JBI  in 
accordance  with  its  pass. 

5.  If  the  pass  is  not  validated,  permission  to  interact  is  denied. 


Figure  4:  Strawman  Force  Template  Interaction  Model 


As  discussed  earlier,  the  force  template  contains  all  passes  associated  with  the  entity’s  clients.  The  pass 
contains  the  approved  advertisements  and  subscriptions  for  a given  client  (refer  to  Table  1).  After  the 
entity  registers,  its  passes  are  maintained  by  the  JBI  platform.  When  the  client  registers,  it  submits  an 
encoded  reference  to  the  pass  that  is  compared  to  the  version  on  the  JBI  side.  If  they  match,  the  client  is 
given  permission  to  interact  with  the  JBI;  otherwise,  permission  is  denied. 

Once  successfully  registered,  the  client  can  then  initiate  JBI  operations  (e.g.,  advertise,  publish, 
subscribe,  and  query)  for  approved  information  objects.  If  the  client  needs  to  change  its  profile,  this 
request  is  forwarded  to  the  corresponding  FTC  (through  the  client’s  adapter).  If  the  request  is  consistent 
with  the  force  template  permissions,  then  an  affirmative  response  is  sent  back  to  the  client.  As  a result,  the 
client’s  adapter  on  the  JBI  platform  updates  the  pass.  If  a negative  response  is  given,  however,  the  request 
is  elevated  to  the  appropriate  authorizing  authority  for  further  consideration. 
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Correspondingly,  if  changes  are  directed  from  above  (the  legitimate  authority  within  the  entity,  a 
parent  of  the  entity,  or  from  the  JBI  information  staff),  then  those  changes  are  also  routed  through  the  FTC. 
Since  these  changes  are  directed  (not  requested),  the  force  template  is  automatically  updated.  This  causes 
the  changes  to  propagate  back  down  to  the  passes  of  the  affected  clients.  These  changes  may  result  from 
higher  level  approval  of  a client’s  request  that  was  initially  denied  by  the  FTC. 

Note  that  the  copy  of  the  force  template,  and  associated  passes,  updated  during  the  mission  is  the  one 
maintained  by  the  JBI  platform.  The  entity  still  retains  its  copy  of  the  original  force  template  submitted. 
Because  the  entity  can  access  (copy)  the  current  force  template  at  any  time,  it  can  choose  to  save  versions 
of  the  force  template  as  it  evolves.  If  desired,  these  saved  versions  can  then  be  used  in  the  future  (instead 
of  starting  over  with  the  original). 

5.  Impact  on  Coalition  C2I  Operations 

In  this  section  we  discuss  how  the  force  template  model  enhances  coalition  C2I.  For  the  sake  of  this 
exercise,  it  is  assumed  that  all  in-theater  coalition  possess  the  credentials  and  systems  necessary  to  interface 
with  the  JBI.  Recall  that  when  each  coalition  member  registers  with  the  JBI,  their  force  template  will  (at  a 
minimum)  define  what  information  they  need,  what  they  have,  and  the  constraints  associated  with  each. 

Although  the  JBI  will  be  primarily  oriented  toward  military  forces,  the  force  template  mechanism  will 
provide  the  flexibility  to  accommodate  relatively  ad-hoc  coalitions.  To  be  successful,  military  operations 
other  than  war  (MOOTW)  will  require  the  participation  of  a wide  variety  of  organizations,  including  local 
civil  authorities  and  NGOs  [2].  As  a result,  future  C2I  systems  must  be  designed  with  these  organizations 
in  mind  and  provide  flexible,  appropriate  mechanisms  for  interfacing  with  them.  In  cases  where  these 
organizations  are  operating  in-theater,  they  can  help  provide  essential  services,  such  as  humanitarian  relief, 
and  may  (indirectly)  serve  as  important  sources  of  intelligence.  In  turn,  these  organizations  must  be 
protected  without  compromising  military  operations.  Successfully  integrating  these  organizations  into  a 
common  C2I  environment  will  be  complicated  by  the  fact  they  have  fundamentally  different  missions, 
practices,  ontologies,  and  equipment  from  the  involved  military  units.  While  not  a total  solution,  the  force 
template  acts  as  a general-purpose  repository  for  information  that  describes  these  aspects  of  each  entity; 
future  C2I  applications  can  draw  on  these  building  blocks  to  overcome  these  problems. 

Regardless  of  the  coalition  member’s  identity,  their  validated  force  template  will  serve  as  the  basis  for 
deciding  how  their  information  is  utilized,  and  by  whom.  Once  an  entity  registers  with  the  JBI,  the 
information  products  they  promise  to  provide  can  be  brokered  according  to  their  specified  constraints.  This 
enables  each  coalition  member’s  information  requirements  to  be  intelligently  matched  with  the  resources 
designated  as  accessible  to  that  member.  As  part  of  this  process,  the  JBI  will  identify  the  available  fuselets 
that  can  be  used  to  transform  sensitive  published  information  into  a form  that  is  releasable  to  the  coalition 
member.  The  JBI  user  will  also  be  able  to  browse  resource  directories  and  identify  useful  categories  of 
information  objects  not  currently  available  to  him  (if  those  entries  are  not  masked).  Once  identified,  the 
member  can  use  his  force  template  as  the  basis  for  negotiating  access  to  these  resources  from  the  publisher. 

Although  there  is  no  guarantee  that  all  of  a coalition  member’s  information  requirements  will  be 
satisfied  by  this  process,  it  enables  him  to  leverage  the  full  range  of  resources  (both  information  and 
services)  available  to  meet  his  needs.  Given  this,  the  coalition  member  may  be  able  to  satisfy  his  needs 
from  an  ad-hoc  collection  of  available  sources,  rather  than  relying  on  a single  source.  Thus,  in  contrast 
instead  of  the  wholesale  denial  of  information  that  commonly  occurs  today,  the  JBI  infrastructure  will 
make  it  possible  for  the  member  to  get  some  subset  of  what  he  needs.  Within  this  context,  the  force 
template  serves  as  an  important  enabling  mechanism  to  fashion  flexible,  information  solutions  for  a diverse 
set  of  coalition  users. 


6.  Conclusion 

If  the  last  decade  is  any  guide,  future  military  operations  will  be  carried  out  by  dynamic,  diverse 
coalitions  composed  of  military,  civil,  and  NGO  members.  The  key  to  success  in  these  operations  will  be 
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insuring  that  these  entities  can  quickly  exchange  both  information  and  service  resources  within  an 
information-centric  C2I  infrastructure  (infosphere).  We  have  introduced  the  force  template  as  an  enabling 
mechanism  to  facilitate  this  interaction.  In  this  paper,  we  have  taken  a first  cut  at  the  force  template 
concept  by  defining  what  it  might  contain.  We  also  introduced  a model  for  how  it  can  be  used  to  integrate, 
and  control  the  interaction  of,  operational  entities  (including  their  children  and  clients)  with  the  JBI 
infrastructure.  Ultimately,  the  force  template  serves  as  a repository  for  mission  critical  information  about  a 
battlespace  entity;  this  information  includes  its  identity,  what  it  wants,  what  it  has  to  offer,  and  how  it 
intends  to  operate  within  the  theater.  With  these  items,  the  infosphere  will  be  able  perform  contextual 
brokering  of  the  available  resources  of  each  infosphere  member.  The  net  result  is  that  infospheres,  such  as 
the  JBI,  can  become  flexible  platforms  for  the  exchange  of  information  and  services  among  coalition 
partners,  insuring  (to  the  extent  possible)  that  the  right  resource  gets  to  the  right  member  at  the  right  time. 
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